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FOREWORD 

The Space Station Systems Technology Study (Contract NAS8-3 <f 893) was initiated in 
3une 1983 and to be completed in April 198^f. The study was conducted for the National 
Aeronautics and Space Administration, Marshall Space Flight Center, by the Boeing 
Aerospace Company with Spectra Research Systems as a subcontractor. The study final 
report is documented in three volumes. 

DlSO-27935-1 Vol. I Executive Summary 

DlSO-27935-2 Vol. II Trade Study and Technology Selection Technical 

Report 

DlSO-27935-3 Vol. Ill Technology Advancement Program Plan 

Mr. Robert F. Nixon was the Contracting Officer's Representative and Study Technical 
Manager for the Marshall Space Flight Center. Dr. Richard L. Olson was the Boeing 
study manager with Mr. Paul Meyer as the technical leader and Mr. Rodney Bradford 
managed the Spectra Research Systems effort. A listing of the key study team members 
follows. 
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1.0 INTRODUCTION 

This is the Executive Summary which is volume I of the final report on the Space Station 
Systems Technology Study conducted for the Marshall Space Flight Center (MSFC) by the 
Boeing Aerospace Company (BAC) and Spectra Research Systems (SRS). The overall 
study objective was to identify, quantify, and justify the advancement of high-leverage 
technologies for application to both the early and more advance space station. Research 
plans were developed for each of the selected high-leverage technologies. The objective 
was fulfilled through a systematic approach tailored to each of the tedinoiogy areas 
studied. 

The current Space Station Systems Technology Study was an outgrowth of the Advanced 
Platform Systems Technology Study (APSTS) which was completed in April 1983 for 
MSFC by the Boeing/SRS team. The first study proceeded from the identification of 106 
technology topics to the selection of five for detail trade studies. During the Advanced 
Platform Systems Technology Study, the technical issues and options were evaluated 
through detailed trade processes. Individual consideration was given to costs and bene- 
fits for the technologies identified for advancement, and advancement plans were devel- 
oped. An approach similar to this was used in the current study with emphasis on system 
definition in four specific technology areas. 

The four study areas addressed in the Space Station Systems Technology Study are: 

(1) Attitude Control, (2) Data Management, (3) Long-Life Thermal Management, and 
Automated Housekeeping Integration. These four areas are extensions of areas identi- 
fied during the APSTS and were conducted to facilitate a more in-depth understanding 
of the technology issues. While high-leverage technology identification was a study goal, 
different study approaches were used for each study area. The attitude control study 
utilized a specific representative configuration and determined by simulation the applic- 
ability of a low-bandwidth control system for space station use. Tile data management 
task concentrated on the architecture characterization into structural blocks and sys- 
tems to facilitate simulation planning. The tiiermal study focused on characterizing a 
two-phase heat transport systems within the long life requirement constraints. The 
automated housekeeping task was structured to characterize the functions of an inte- 
grated controller for an overall management system. Each of these approaches produced 
useful advancements in the understanding of technology issues and development needs. 
The summary discussions are presented in the following sections. 
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The overall study was divided into four tasks. During task 1 the design concepts in each 
of the four study areas were refined. The concepts were used to annunciatii; specific 
technology options upon which comparative studies were conducted* Candidate high- 
leverage advancement technologies were then selected from the options. The cost, 
benefits, schedules, and life cycle costs for the options were evaluated in task 2. Selec- 
tion of the technology advancement items was made during this latter task. Technology 
advancement plans were prepared for each of the selected items in task 3. All study 
documentation was prepared in task 4, The overall study plan flow diagram is shown in 
figure 1.0-1. 

This volume presents a summary of the work performed to select these high leverage 
items. The total final report is made up of this volume, Volume II: Trade Study and 
Technical Selection Technical Report, and Volume III: Technology Advancement Pro- 
gram Plan. More detailed discussion of the trades conducted and the technology 
advancement plans are given in volumes II and III respectively. 

1.1 TECHNOLOGY SELECTIONS AND RATIONALE 

Seven potential technology advancement items were identified during this study. These 
items were analyzed and evaluated in task 2, considering technical as well as cost bene- 
fits and schedule criteria. Study plans were prepared for each of the selected high lever- 
age items. These selected items are: 

1. Data Management System Simulation Package. 

2. Data Management Network Interface Unit. 

3. Data Management Network Operating System. 

4. Two Phase Thermal - Long Life Pumps. 

5 . Two Phase Tliermal - Heat Exchanger. 

6. Two Phase Thermal - Two Phase Water System. 

7. Integrating Controller for Space Station Autonomy using Expert Systems. 

The follov^ing sections summarize the rationale associated with selections made in each 
of the four study areas. 
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1.1.1 Attitude Control Rationale 

The objective of the attitude control study was to investigate a control system concept 
thru simulation modelling to assess whether a core-mounted reactive controller could 
provide satisfactory attitude control of a typical space station. The simulations were 
run, and the results indicate that a core-mounted controller that reacts to disturbances 
fed back thru the structure is stable. The simulation results did expose a potentisil prob- 
lem area due to very lightly damped oscillations at the astromasts in response to 
modelled one shot disturbances. These oscillations appear to be of low amplitude and 
therefore may not be disruptive to the space station. Modelling of the effect of cumula- 
tive disturbances is indicated for future studies. 

The reason this simulation approach was taken is that speculation has been extensive on 
how difficult the flexible dynamics of the station would be to control. This simulation 
study is a start toward a better understanding of that problem, and a better understand- 
ing of where technology advancements are really needed in the attitude control area. 

1.1.2 Data Management Rationale 

The rationale for die technology selections in the data management area is that the 
system will be complex and highly interactive with other systems and with missions of 
the space station. An early simulation is therefore required of the data management 
system allowing synthesis of the local area network (LAN) and sizing of data manage- 
ment system components. The simulation package definition, in the presence of all the 
undefined complexity of the space station at this time, is a technology advancement 
effort that needs to be started. 

The Network Interface Unit and Network Operating System advancements are the hard- 
ware and software areas needed to support the development of a local area network for 
the space station. Within these two areas, several specific items are recommended for 
advancement and are listed on figure 2.3-9 of this volume. Examinations of the study 
configurations and concepts did not reveal any specific technology that is likely to be a 
show stopper if not advanced. However, the general complexity of the system and the 
data management interfaces indicate that early structuring thru simulation is essential. 
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The cost benefits analysis of the APSTS was not changed by the conclusions of this study. 
The reduction in system development and operating costs thru use of a well defined local 
area data management network remains as an impressive eight dollar saving of system 
integration costs for every dollar spent in establishing an early structuring of the data 
management system. 

1.1.3 L(H)g Lifetime Thermal Rationale 

The rationale for the technology selections in this area is based on the results of an anal- 
ysis of the weight, size, and complexity of two-phased heat transport system concepts as 
compared with pumped liquid concepts. The first result of the study is that the two- 
phased concepts will be several thousand pounds lighter than the single phase liquid sys- 
tems. The second result is that use of a two-phased loop for the interior cabin heat 
transport would improve ihe weight advantage of the two-phased system by approxi- 
mately 1000 additional pounds. This internal two-phased loop would also provide design 
flexibility to support space station evolution. For these reasons, the development of a 
two-phased (non toxic) water loop for heat transport within the space station pressurized 
cabins is selected as a primary technology for advancement. 

Further technology advancement effort to improve the life of pumps operating in space 
is based on existing studies that indicate that current centrifugal pumps are unlikely to 
operate continuously for the 10 years associated with the space station. Heat exchanger 
tedinology advancement is also indicated especially when two-phased systems are used 
both for the pressurized module heat transport and the main heat transport system on 
the space station. 

TTie cost benefits analysis for these technology advancements is detailed in section ^.3.9 
of volume U. In summary, the benefits are based on transportation cost savings due to 
weight reduction, radiator assembly cost savings due to smaller area, and system devel- 
opment cost savings due to reduced complexity (RCA-PRICE modelling was used here). 
The costs were the estimated technology advancement costs. The result was that eight 
doiiars in quantified benefits could be achieved for every three dollars spent in advancing 
the technologies in this area. 
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l.i.4 Integration of Automated Housekeeping Rationale 

The concept development group for tiie space station task force has established an 
autonomy/automation philosophy for the space station (see table 2,5- 1)» This philosophy 
is in agreement with the needs of a space station to provide a facility for a wide range of 
missions without encumbering the crew (or mission controllers) with excessive hours for 
station upkeep. This philosophy is also in agreement with the needs for efficient and 
balanced operation of the space station complex systems over extended lifetimes with 
limited consumable and power resources. The rationale for autonomous systems to pro- 
vide housekeeping of the space station is that they are completely consistent with the 
needs of a meaningful long life and evolutionary space station concept. 

The rationale for the development of an integrating controller is that the controller is 
necessary for space station autonomy because it provides overall decision-making func- 
tions to replace those that would otherwise have to be provided by human mission con- 
trollers or astronauts. The results of developing the integrating controller may also 
drive out needs for advancements in space qualified data processing equipment, sensors, 
actuators, and devices for interacting with the crew. If advancements in these areas 
are needed, the development lead times may be long so tiiose needs should be identified 
by starting and advancement program for the integrating controller as soon as possible. 

The cost benefits assessment of this study resulted in some modification of the con- 
clusions of the Advanced Platform Study completed in April of 1983. The cost modifi- 
cation was based on higher costs due to higher labor rates and a more detailed under- 
standing of the functions of the concept. Hie benefits were modified due to a consid- 
eration of phased application of the tedinology to the space station over a ten year 
period. The result was that the cost versus benefit ratio changed from one to ten to four 
to ten. This still provides an impressive return on the advancement dollars spent and 
does not consider the significant unquantifiafale benefits of the integrating controller. 
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2.0 TECHNICAL SUMMARIES 

This section summarizes the results of the trade study and technology advancement plan- 
ning efforts conducted for the Space Station Systems Technology Study. 

2.1 INTRODUCTION 

The trade study effort conducted on Space Station Systems Technology Study character- 
ized system concepts in order to define cost versus benefits for data management archi- 
tecture, long-life thermal management, and integration of automated housekeeping. The 
attitude control topic selected for study focused on characterizing the space station 
attitude control problem through simulation of non interacting controi system responses. 
The first three topics, mentioned above, focused on specific technology items that re- 
quire advancement in order to support a 1990 initial launch of an early space station, 
while the attitude control study was an exploration of the capability of a conventional 
controller. 

The characterization studies were structured to start with the issues identified in the 
Advanced Platform System Technology Study completed in April of 1983. Investigation 
of these issues motivated consideration of a more detailed characterization of the four 
topics that were then covered in this current study. A definition of concepts based on 
space station needs and constraints was developed for each of these areas as an initial 
step in the current study. These concepts were based on requirements that were derived 
from space station related documentation or from requirements Itnown to exist for simi- 
lar missions. The next step was to develop the characterizations to identify options 
within the trade topics. Based on life cycle costs and benefits the options were then 
evaiuated and technologies necessary to support the more promising options were identi- 
fied. 

Cost and schedule factors related to advancing the technologies recommended in the 
data management, long lifetime thermal management and integration of automated 
housekeeping areas are also summarized in this section. 

The four study topics are presented in this final report in the order that was established 
by the RFP. That order is attitude control first, then data management architecture, 
long-life thermal and lastly, integration of automated housekeeping. A summary of the 
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study approaches and resuits of the four topics is presented in this voiume. Detaii trade 
study technical information is in volume II, and detailed advancement planning infor- 
mation is provided in volume III. 

2^ ATTITUDE COI«TROL 

The objective of the attitude control study was to examine the technologies required for 
solving the control-structure interaction problem in space station design. The approach 
was to determine through analysis and simulation the degree to which noninteracting 
low-band controller technology is applicable to attitude regulation of a space station 
with large flexible solar arrays. Primary emphasis was given to identifying the limita- 
tions of low-band controller technology for flexible space station applications. Passive 
and active control technologies were to be reviewed as potential improvements to the 
damping provided by a low-band controller in the event that attitude stability and per- 
formance was unacceptable. 

In this study ail the available attitude information, including flexible effects as measured 
by an ideal sensor package mounted on the core station, is passed to ideal control 
moment gyros (CMG) actuators that attempt to control the attitude about the center of 
mass. The low band controller will therefore attempt to regulate attitude in the pres- 
ence of Induced disturbance torques due to flexibility without actively controlling the 
motion of the flexible elements. This simulation study demonstrated that a co re- 
mounted linear ideal controller is stable in the presence of flexibility and will provide 
significant damping of most of the major structural modes. Some of the modes, how- 
ever, cannot be controlled with a core mounted controller. The important issues are the 
amplitude to which those modes are excited and the implications of sustained vibration 
of the associated structural members. 

Tight-pointing accuracy requirements could produce associated requirements for 
increased control system bandwidth. As controller bandwidth increases, many structural 
modes will be included within the controller passband. Active stabilization of these 
modes without sacrificing pointing accuracy is another major issue. Adapting to varia- 
tions in mode shapes and frequencies caused by space station configuration changes is 
also a major issue. 
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2.2.i Technical Approach 

The technical approach is formulated in terms of five main tasks. These tasks are iden- 
tified in the discussion to follow. 

The first task in the process was to select the configuration for the space station tech- 
nology study. This was derived from the limited class premise with adherence to the 
NASA governing assumption which is "a space station as a permanently inhabited facil- 
ity engaged in productive work and delivered to low earth orbit in stages the dimensions 
of which are consistent with tiie shuttle cargo bay." 

The second task was to develop a schematic architecture consistent with the functional 
attributes and incorporating various strategies for growth leading to a 12-man configura- 
tion representative of shuttle deliverable hardware. 

The attitude control study considered four operational stages that incorporate two 
phases of assembly, with and without the orbiter docked. The two phases of assembly 
will include the initial habitable stage and the all-up fully operation^ stage. 

A pictorial view of the study configuration is shown in fig. 2.2-1. A representative build 
up sequence is shown in fig. 2.2-2 along with the stages selected for analysis. 

Mass balance was a principal design goal in order to ensure that CMG controllers will 
enable attitude stabilization with minimal expenditure of energy for momentum manage- 
ment. Dynamic balance is achieved by center pivoting the solar panels. This configur- 
ation eliminates dynamic products of inertia that arise as the panels are rotated to track 
the sun line. The center mounted solar panels also increase the lowest frequency struc- 
tural mode by a factor of two due to halving the length of the solar panel deployment 
mast* 

The third task was to develop a finite element model of the station and the resulting 
mass and stiffness distribution of the structure into NASTRAN. The output modal data 
from NASTRAN established the normal mode shapes and natural frequencies of vibration 
for the simulation. 


3 


DlSO-27935-i 


The fourth task was to develop a system of analysis programs for control and structure 
interaction analysis and simulation* and these are shown in fig. 2.2>3. Finally* the anal- 
ysis of attitude control system stability was performed by arguments based on the theory 
of positivity of operators. The basic stability theory was verified by frequency response 
methods and time response from simulation of the closed loop system. The performance 
of the closed loop system was determined from time response data. System performance 
includes the motions of the central core and the flexible elements. Stresses at the root 
of the solar array boom and astromast were derived from time response data. 

2.2.2 Technical Discussion 


The simulated response of the structure to the test disturbance represented by an im- 
pulse doublet was computed for bolfi open loop and closed loop cases (see figure 2.2-4). 
The block diagram for the closed loop system representing an attitude regulator is shown 
in figure 2,2-5. The nodal structure indicating the nodes used to extract measurement 
data is shown in figure 2.2-6. Motion of the core structure relative to an inertial frame 
was extracted from the rotational state of the variables 4 > , 0 ,ij» (roil, pitch, and yaw, 
about X, y, z) of node 100. Measurements of flexible element motion relative to node 
100 are specified as follows. These rotational measurements indicate the ilex and twist 
of the solar panel boom and the astromast structure, 

panel boom (4*100-105) 
a Twist of panel boom (0100-105) 

= Flex of panel boom (%00-105) 

= Twist of the astomast (<j>i0O-323) 

= Flex of the astomast (0105-323) 


^By 

Mb^ 

MAx 

MAv 


The quantitiese{jj,£ 0 *E^represent the contribution of the flexible modes to the total 
attitude response. For example 0 = 0f is the total rotational response of node 100 
about the pitch axis and 0f is the component due to the free - free motion only. It is 
noted that quantities MBj^, Mb 2 > ^nd M/^^ represent the mode slopes at the end of the 
associated flexible members. All response cpantities are in arc-sec. 


2.2.2.1 Control System Responses 

Examples of the simulated response of the attitude regulator to the test disturbance are 
shown in figures 2.2-7 thru 2.2-9. The system bandwidths chosen for presentation are 
,05 Hz for configuration 1 and ,25 Hz for configuration 2. The controller was a simple 
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proportional plus derivative feedback of free - free mode attitude measured at node 100 
(fig. 2.2-6). The time responses indicate that regulated free - free mode attitude is both 
stable (in accordance with theoretical predictions) and controllable. The controllability 
of the structure is not surprising because the impulse energy analysis has clearly indi- 
cated that controllable normal modes contain motions of all structural elements with the 
exception of the astomast twist. The time responses support this claim and would indi- 
cate that torsional vibrations of the astomast are not controllable with the controllers 
and sensors mounted on the rigid core as expected. 

It is noted that the rate of suppression of vibration (damping) in the structural elements 
appears to be independent of vehicle inertia for fixed free - free mode control band- 
width. However, the magnitude of the vibration is, of course, inversly proportional to 
vehicle inertia as expected. The damping of structural vibrations for a given vehicle 
inertia decreases with increasing free-free mode control bandwidth. This is due to the 
fact that with increasing bandwidth the closed loop modal poles approach the open loop . 
modal zeros, which are virtually undamped. The result is that the residual in the 
response due to a given modal pole is reduced but so is the closed loop damping on that 
pole. 

The response of the structure to a typical orbiter docking from impact loading at body 
station 1201 is shown in fig. 2.2-10. It is assumed that the orbiter has an initial rota- 
tional rate at docking about its c.g. of q= .2 deg/sec with a linear velocity of 

Q~ .15 m/sec as shown in figure 2.2-11. Assuming the centerline of shock is 1 meter 
from the station c.g. and further assuming that the collision is perfectly elastic, the 
resulting impact will impart approximately 2500 N-sec to the station. 

2.2.3 Summary of Results 

The important control and structure Interaction issues for a representative space station 
configuration have been addressed. Specifically, the stability and performance of the 
station with a core-mounted linear controller has been investigated. The inertias are of 
order 10^ with solar panel size of 1100 m^, which is consistent with a 75 kW power re- 
quirement. The following statements summarize the results of the study. 

1. Analysis has shown and the simulation has verified that the raft configuration is 
stable and controllable when ideal sensors and CMG actuators are colocated. 
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Figure Z2-J0. Impulse Response {arc-sed of Configuration 1 to Docking Load 
of 2500 Newtons at Body Station 1201 (Force Along X-Axis} 
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Because the raft is rigid at frequencies of interest (0.5 - .5 Hz), colocation of ideal 
sensors and actuator on the raft will guarantee stability. 

2. Damping of the structural modes is substantially augmented in most cases by the 
CMG core mounted controller. Damping of astromast torsional vibrations is not 
augmented by the core mounted controller. 

3. The performance of the ideal reactive controller to suppress transient disturbances 
at levels of practical interest is limited only by the control authority. The issues 
addressed in the current simulation work are therefore related to the assumption of 
ideal (infinite band-width noise free) sensors and actuators. 

Simulation shows no extreme motions of flexible elements when subject to the most 
severe shocks due to docking loads. The loads were modeled as impact forces at the 
docking interface. The maximum stress at the roots of the array boom and astro- 
mast are at least a factor of 100 less than the proportioned limit stress. 

5. Gimbal rate response to the test impulse doublet was found to be as high as 6°/sec 
for controller bandwidth of .05 Hz. Skylab class gyros are rate limited to 4-6°/sec. 
Therefore, if bandwidth above .05 Hz is required for the class of space station 
studied here, then three Skylab gyros is the minimum number to ensure accuracy of 
100-200 arc sec under the assumed level of transient loads. 

2 . 2 .^ Conclusions 

The conclusions of the study can be summarized as follows. Control of the free - free 
attitude modes using a regulator consisting of colocated CMG actuators and ideal rate 
and position sensors is asymptotically stable. However, the response of flex modes asso- 
ciated with the astromast is lightly damped with long settling time. If the resultant low 
amplitude vibrations are objectionable, then flex mode damping must be introduced. 
Investigation of passive damping techniques should be a first priority. With these results, 
the important issues of core station free - free mode attitude control using a simple con- 
troller without additional stability, augmentation of the flex modes has been addressed. 
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2^.5 Recommendations 

Continuing effort in attitude control for space station should concentrate on defining 
control requirements during build-up and construction phases including configuration 
with the orbiter docked. Emphasis should be given to definition of control modes for 
each phase of evolution and schemes for managing the momentum envelope of candidate 
momentum transfer systems. Control modes would include electromagnetic sensing and 
actuation, momentum transfer, mass expulsion, attitude biasing, and appendage 
articulation. 
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2^ DATA MANAGEMENT 

Data management includes the data system hardware and software needed to provide ail 
Space Station data processing, storage, and communications for onboard users, subsys- 
tems and payloads. This study was based on requirements determined in the Advanced 
Platform Systems Technology Study as shown in figure 2.3-1, and extended that work as 
summarized by the paragraphs that follow in this section. 

2.3.1 Approach 

Specifically, the three areas of data management extension for the Space Station Sys- 
tems Technology Study are: 

1. Mission configuration analysis. 

2. Network Interface Unit (NIU) description. 

3. Network Operating System (NOS) definition. 

The purpose of the configuration analysis subtask was to assess the impact of candidate 
Space Station missions on the DMS, to ensure that the concepts developed in the previous 
study would meet all requirements. This analysis was used to develop a DMS model for 
future simulation studies, and also provided an input to subtaste two and three. The NIU 
and NOS were identified in the APSTS, and a cost benefits analysis was conducted to 
determine their potential value to the program. It was estimated tiiat a potential sav- 
ings of $176M could be realized if the LAN were developed, and if the onboard subsys- 
tems and payloads used the LAN hardware and software for data collection, processing, 
storage, and communications. The higher cost alternative would have each experimenter 
develop his own DMS hardware and software, followed by a systems integration step to 
make the payload compatible with the onboard data management system. This approach 
results in needless duplication of effort, when compared to the LAN. Also, the- savings 
of $176M refers only to development costs. It is believed that the LAN would also yield 
significant savings in operational costs, due to the ease of msuntenance resulting from its 
standardized, modular organization and due to the reduction in logistics requirements 
brought about by the use of a small set of common modules. 

The first subtask under study task one, was to investigate the impact of possible Space 
Station mission configurations on the DMS, so that data communications bandwidths. 
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Figure 2.3- 1 Data Processing, Storage and Communications Requirements 
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data storage capacities, processing requirements and interfacing requirements could be 
estimated. Three mission models were investigated, including Construction and Mate- 
rials Processing Station (CAMPS), Communications and Data Management Station 
(CADMS), and Land, Ocean, and Atmospheric Research Station (LOARS). 

After completion of the mission configuration analyses (subtask 1), the impact on the 
DMS hardware and software systems could be assessed more readily. This permitted the 
primary hardware element of the DMS to be analyzed and described in greater detail, as 
subtask 2; with the primary software element defined functionally, as subtask 3. These 
elements are the Network Interface Unit (NIU) and Network Operating System (NOS), 
respectively. Together, they comprise the onboard LAN that integrates the subsystems, 
instruments, user interfaces, and other equipment that require data management serv- 
ices. The NIU provides the system connection points or interfaces, while the NOS con- 
trols the data communications, storage, and processing activities of the DMS. 

2.3.2 Technical Discussion 

Figure 2.3-2 shows how the backbone local area network might fit into a typicEil space 
station configuration called the raft structure. The heavy lines are bundles of optical 
fibers, that interconnect the network interface units. 

The topology can be described as a two-level hierarchy. The NIUs and their intercon- 
nections provide for communication between station modules, and form the upper level 
of the hierarchy. The devices connected to the links and buses within the modules, sup- 
ported by the NIUs, form the lower level. This approach allows for modularity at both 
levels. The NIUs handle Intermodule communications through standard bertliing-port 
interfaces, allowing station modules to be plugged-in at any berthing port. At the lower 
level, sensors and medium-speed devices can be plugged into the NIUs by means of stand- 
ard interface cards and standard buses. 

The multi-star and graph fiber-optic backbone network topologies appear to be viable for 
the station} they are shown in figure 2.3-3. The diagram shows the two possible methods 
for interconnecting the station NIUs by means of fiber optics. The set of lines drawn 
above the boxes represents the interconnection topology formed by the use of four opti- 
cal start couplers, located near NIUs C, D, E, and F. For example, the coupler located 
at NIU-C interconnects A through E, as shown by the lowest horizontal line. In this 
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example^ each of the coupiefii would interconnect a subset oi five of the eight NIUs, so 
four five-port couplers would be required. The set of lines drawn below the boxes repre- 
sents a point-to-point interconnection topology. Each link consists of a bidirectional 
channel, using two fibers with transmitters and receivers at opposite ends. Store-and- 
forward communications techniques are used, as opposed to the shared-bus techniques 
needed for the multi-star topology. 

The transmitter and receiver logic is essentially the same in both cases, as shown in 
figures 2.3-it- and 2.3-5. These figures are block diagrams of the circuitry needed to 
implement optical transmitters and receivers, with the exception of the control logic. 
The transmitter converts digital data residing in memory to a serial bit-stream, encodes 
it with clock information, and uses the resulting signal to modulate an optical source. 
The receiver uses an optical detector to convert tile signal back to an electrical form for 
decoding and conversion to a parallel word format that can be stored in a memory 
buffer. These examples use a 32-bit memory and a 100 MHz serial data rate, so the 
required memory cycle time (320 ns) is relatively slow. 

The two configurations use different access protocols for multiplexing the communica- 
tions media. The graph topology uses simple TDMA, while the multiple-star topology 
may use polling, contention, or token-passing. In a polling system, one of the P^Us func- 
tions as a controller, polling each of the other NIUs In sequence to enable them to trans- 
mit data, one after the other. In a contention scheme, each NIU acts independently and 
listens for activity on the communications channel. If the channel is not busy, the NIU 
can transmit; however, two may transmit almost simultaneously, resulting in a collision. 
They must detect such bus contention, back off, and try again after a random delay in- 
terval. In a token-passing configuration, the system is initialized so that one of the NIUs 
owns a logical token that enables it to transmit a packet. After completing its trans- 
mission, it then sends the token to another NIU, which may transmit and then pass the 
token to the next NIU in sequence. 

At this point, no clear reason seems to exist for choosing a pure graph or a pure multi- 
ple-star topology over the other. It is believed that data management network simu- 
lation studies are needed before a final configuration can be chosen. 
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2.3.2.1 Network Interface Unit (NIU) 

As diown in figure 2.3-6, the NIU is defined as a set of standard circuit cards that plug 
into a high-speed paraiiei data bus, housed in a rack-mountable chassis. The cards pro- 
vide high-speed sensor control and data acquisition interfaces, instrumentation bus inter- 
faces, fiber-optic intermodule communications transceivers, and many other types of 
input-output (I/O) interfaces and controllers. 

The results of the study in this area indicate that the NIU should be modular, and should 
have a high performance potential. Space Station requirements will surely change over a 
period of many years, and ihe basic NIU chassis and high-speed parallel bus can suppxirt 
such changes and upgrades if they are designed with flexibility in mind. 

Development of NIU modules will be a major project, because a dozen or more standard 
electronic modules will have to be spedfied, designed, and fabricated to meet most of 
the potential station applications, such as data acquisition or subsystem interfacing as 
follows: 

1. NIU control processor and cache memory. 

2. Fiber-optic communications transcdver. 

3. Instrumentation bus interface controller. 

RF communications transceiver interface. 

5. Digital voice communications interface. 

6. Crew station console/CRT interface. 

7. High-speed sensor data buffer. 

S. Ma^etic tape mass memory controller. 

9. M acetic disk mass memory controller. 

10. Color video <5c graphics I/O controller. 

11. Analog I/O interface. 

12. Discrete digital parallel interface. 

Custom modules would also be needed, for specialized applications such as high speed 
sensors. 
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Figure 2.3~6 NiU: Internal Organization 
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2^.2^ Network Operating System (NOS) 

An operating system is the coliection of software processes and functions that control 
computer systems, as shown in figure 2.3-7. In a distributed system environment, or in a 
local area network, the term network operating system (NOS) is frequently used, and has 
been adopted here. Aboard the Space Station, the NOS is conceived to have two major 
functions. First, it provides the operating environment for DMS mers. Second, it man- 
ages the overall operation of the devices attached to the network, supporting status 
monitoring and control functions, and providing data storage, communications and proc- 
essing services. 

Development of an automated diagnostic and reconfiguration software system, as part of 
the NOS, appears is be a major task. So-called nonstop computer systems exist, but they 
are not in common usage and are not 100% effective. It would appear that more effort 
is needed if such a capability is to be available for use aboard the station. One of the 
most promising approaches to such a technology development is the use of software sim- 
ulation to model the DMS and the NOS, and to test the response of the system to the 
injection of simulated faults. 

As mentioned above, a prime development task is to determine how automated diagnos- 
tic and reconfiguratic»i software can be implemented. Figure 2.3-8 shows how a DMS 
simulation process can be used to inject errors and hard faults into the model, to deter- 
mine the impact on system functionality, and to test 1lte performance of automatic 
reconfiguration algorithms. 

The simulation package consists of several software modules, as shown in the diagram. 
The most important are the producers, servers, consumers, and the instrumentation 
module. Producers simulate the production of messages or packets that, in a real sys- 
tem, would be transmitted by the devices that make up the DMS. The servers simulate 
the behavior of the network communications components and software protocols. Con- 
sumers are the devices to which the messages or packets are sent. And finally, the in- 
strumentation module performs data collection and simulatec' fault injection. 

The simulation package will allow the use of modern CAE techniques in DMS design, in 
the same way and for the same reasons that integrated circuits are designed and simu- 
lated prior to fabrication. Simulation can give excellent indication of system perform- 
ance, before major resources are committed to production; and, various concepts can be 

traded and compared to produce an optimal design. 
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2.33 Conclusions and Recommendations 

Tlie work performed during the data management study led to conclusions in data man- 
agement system configurations, system hardware (NIU), and system software (NOS). 
Three potential mission configurations were analyzed, with the Land, Ocean, and Atmos- 
pheric Research Station (LOARS) model developed in enough detail for simulation studies 
to commence. The NIU was analyzed to the point where component technologies could 
be identified? and the NOS was defined to a level of detail that included individual soft- 
ware modules and Iheir functional interrelationships. These analyses were then used in 
the second part of the study, task 2, to help in the evaluation of the need for each. In 
the data management study, 16 technology areas were identified during task 1 and were 
scored in 5 categories, with a rating of 0, 10, or 20. These scored technology areas are 
listed on figure 2.3-9. On that figure, a technology needed early in the program is more 
critical to success than one that is needed late, so a score of 20 was assigned. The total 
scores give a rough estimate of the program criticality of each of the 16 technologies. 
TTiat is, an area with a high score is an area that may have a greater program impact. 

An area with a low score, such as the high-speed sensor data buffer, may still be impor- 
tant? however, low cost and risk, combined with a late need and relatively short lead 
time mean that the relative program impact may be quite low. 

The simulator, the NIU, and the NOS are the key elements of the DMS that have been 
identified and described in detail during the Advanced Platform Systems Technology 
study and those elements still appear to provide the greatest cost savings to the pro- 
gram. The total cost of development for tiie three items is $22.^5M over six years. If 
the development cost savings to the program is $176M primarily in reduced systems inte- 
gration costs, then the ratio of benefits (savings) to cost is 7.9. That Is, for every dollar 
spent on network simulation, hardware (NIU) and software (NOS), NASA can expect sav- 
ings in DMS development cost of almost eight dollars. The potential savings in operating 
costs are also considered to be quite significant, and are worth investigating in future 
studies. The main conclusion is that in the Space Station DMS development some tech- 
nologies are needed before others and are, in fact, needed to facilitate development of 
others. 
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Table 2.3-3 Resources for Network Operating System Technology Advancement Program 
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2,3A Technology Advancement Plans 

As a result of system trades In the data management area, several components have been 
pinpointed as offering significant benefits in cost and performance. In addition, some 
items were selected for advancement because they were nec^sary to be built for fiber* 
optic backbone data management system {as described in Volume II) rather than because 
they were more cost effective than other options. For instance, in the case of the net- 
work operating system, there is no alternative but to have one. 

The data management requirements of the early and evolutionary Space Station configu- 
rations represent the near-term and evolutionary goals of the data network. Also, the 
items below were selected for technology advancement because they represent those 
items of a fiber optics data network that are critical since they might not otherwise be 
developed in time for a FY 87 new start on the Space Station. The system development 
and application area will involve a system simulation that is essentially the first genera- 
tion network. Ihe network Interface unit and operating system areas are critical items 
of the second generation network development. 

Figures 2.3-10, -11, and -12 and tables 2.3-1, -2, and -3 provide schedules and resource 
planiiing information respectively for the three data management advancement 
programs. 

2,it LONG-LIFE THERMAL MANAGEMENT 

The objective of the present long-life thermal management study was to identify heat 
transport system technologies that increase performance, enhance system life, and re- 
duce system weight and cost. Emphasis was placed on two-phase heat transport systems 
that offer significant potential benefits. These systems absorb and reject heat at a near 
constant temperature. This simplifies the thermal interfaces and allows thermal loads to 
be placed at any location that provides a high degree of flexibility in reconfiguring the 
space station. Reduced pump power requirements and heat transport by latent heat of 
vaporization provide size and weight reductions compared to a conventional pumped 
liquid loop heat transport system, 'fhese comparisons made possible 1be identification of 
tliree new technology areas requiring advancement. 
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The study approach, technical discussion of study and results ate summarized in the fol- 
lowing sections. 

2,hA Approach 

The trade study was divided into subtasks as outlined below: 

1. Define baseline pumped two-phase heat transport system. 

2. Optimize baseikie system. 

3. Identify optional systems. 

a. Pumped liquid loop, 

b. Capillary two-phase. 

c. Alternate two-phase pumping concepts. 

The trade study groundrules and the basic heat transport systems studied are defined in 
section 2.4.2. The summary of results are presented in section 2.4.3. 

2.4.2 Technical Discussion 

The following paragraphs provide a technical summary of the study conducted for Long- 
Life Thermal Management. 

2.4.2.1 Groundrules for Study 

The following basic groundrules were established for the study: 

1. Heat load: 25-150kW. 

2. Transport distance: approximately 150 ft. 

3. Grumman Space Constructabie Radiator 1.2 Ib/ft^. 

4. Power penalty: 350 Ib/kW. 

5. Heat transport fluids: 

a. Two-phase: OTimonia. 

b. Pumped liquid: Freon 11, Freon 114, ammonia. 

6. Low temperature (about 40°F) heat rejection for metabolic and battery heat 
loads. 

7. High temperature (about S0°F) heat rejection for remaining loads. 

8. Radiation sink temperature: 415°R. 
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9. Pumped water heat transport loop inside pressurized moduies# 

10. Elements for each system; 

a. Radiator. 

b. Cold plates. 

c. Pressurized module interfaces. 

d. Transport loop. 

11. Thermal storage interface inclusion is beyond scope of study. 

During the course of the study, only minor differences were found between the results 
for Freon 11 and Freon 11^. Consequently, the detailed analyses were completed for 
Freon 1 1 only. It also became apparent that a two-phase water heat transport system 
inside the pressurized modules offered benefits; that concept was added to the study. 

Heat Transport Systems 

Figure 2,^f-l shows the basic heat transport systems that were analyzed in this study. 

The baseline is a pumped two-phase system with a liquid and vapor lines. A mechanical 
pump is used to pump the liquid condensate from the radiator to the heat source heat 
exchangers (evaporators). Control valves are used to meter liquid flow to the heat ex- 
changers. The fluid vapor flows to the radiator when it condenses as the waste heat is 
radiated to space. The thermal storage unit is used to provide load leveling and efficient 
use of the radiator. (As noted previously, a detailed analyses of the thermal storage 
interface was beyond the scope of the study.) 

The capillary two-phase system is similar to the baseline system, except pumps and 
valves are not required. The capillary wicks in the heat exchangers provide the required 
pumping action. The pumped liquid loop is similar to the baseline system except that the 
heat is transported as sensible heat rather than as latent heat of vaporization. 

Alternate pumping concepts were briefly considered for the baseline pumped two-phase 
system. One concept would use an osmotic pump in the liquid line. The liquid would 
consist of a solvent and solution separated by a semipermeable membrane. The osmotic 
pressure across this membrane causes solvent flow through the membrane into the solu- 
tion. The solvent evaporates from the solution at the evaporators, condenses in the radi- 
ator and returns to the membrane. The other concept considered uses an ion drag pump. 
This pump uses a high voltage probe to generate and accelerate ions in the fluid. These 
ions exchange momentum with the fluid and produce the pumping action. 



D180-27935-1 



ORtGtNAL PAGE 1® 
OF POOR QUALITfY 


BASEUtWE 

CAPILLARY 

PUMPED 

PUMPED TWOPHASE 

PUMPED WOWASE 

UQUID LOOP 

SYSTEM -r 

T SYSTEM T' *r 

SYSTEM 


COLD 
TLATE HX 


COLO 

fLATEHX 


COLD 
PLATE HX 


MODULE 
WATER LOOP 


INTERFACE 

HX 


PREaURIZEO 

MODULE 

WATERLOO? 


iKTERFACE 

HX 


PRESSURIZED 

module 

WATERLOO? 


INTERFACE 

HX 


COLD 
PLATE HX 


COLD 

plate HX 


COLO 

PLAl^HX 


THERMAL 

STORAGE 


thermal 

STORAGE 


THERMAL 

STORAGE 


RAOrATOR 


RADIATOR 


RADtATOR 


Figure 2 A- 1 Heat Transport Systems 























D 180-27935-1 


2A.2.3 Effect of Two-f^ase Water System In Pressurized Modules 

The interface between the two-phase heat transport bus and the pumped water loops in 
the pressurized modules results in a lowering of the bus temperature in order to mini- 
mize system weight. The reason for this is that the water temperature change must be 
less than the temperature difference between equipment and bus. Consequently^ because 
the water loop transports sensible heat, higher flow rates (and higher weights) are in- 
curred as the temperature difference decreases. A two-phase water heat transport sys- 
tem allows a higher bus temperature and potentially lighter weight system. 

2.4.2.3.1 Two-Phase Water Heat Exdranger and Line Sizing 

The two phase heat exchanger weights were based on a detailed analysis conducted as 
part of the study. Because the water vapor density is low for the temperature range 
considered, the vapor pressure drop (in the vapor line between the equipment and inter- 
face heat exchanger) effect on vaporization (condensation) temperature was included in 
the analyses. 

For the high temperature heat rejection system case the vapor line was fixed at an inside 
diameter of 2.25 inches and the liquid line at 0.5 inch inside diameter. These line sizes 
result in an overall head difference of about 1 Inch, which is compatible with capillary 
pumping. The vapor line pressure drop produces a difference between vaporization tem- 
perature, at the equipment heat exchanger, and condensation temperature, at the inter- 
face heat exchanger of 1.76°F. The heat exchangers were optimized as a function of 
equipment to bus temperature difference that included this fixed vaporization tempera- 
ture difference. 

The effect of pressure drop on vaporization temperature is more pronounced in the low 
temperature heat rejection case. In this case the vapor line size was optimized in con- 
junction with heat exchanger optimization to provide the lowest weight system for a 
given humidity control unit to bus temperature difference. The liquid line size was fixed 
at 0.25 inch O.D. with 0.02 inch wall. 
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2.4.2.3.2 Effect on System Weight 

Figure 2.<>-2 shows the effect of incorporation of two-phase water heat transport sys- 
tems in the pressurized modules on the high temperature two-phase ammonia system 
element weights. The minimum total weight now occurs at a bus temperature of 79°F 
compared to the 70°F optimum for the system with pumped water loops. A detailed 
schematic showing the effects on the two-phase water system is shown in figure 2.^t-3. 
The main bus sizes and weights remain unaffected. TTie equipment cold plate weights 
are increased due to the higher bus temperature. The radiator and pressurized module 
component weights are significantly reduced. The total system weight is 828 lb less than 
that for the system with pumped water loops. 

The effects on the low temperature heat rejection system are shown in figures and 
2,H-5. The optimum bus temperature for this case is 37.5°F compared to 36°F for the 
case with pumped water loops. As in the high temperature case the bus weight remains 
unaffected, the battery cold plate weight is increased and the other component weights 
are reduced. The total weight is 79 lb less than that for the pumped water loop system. 

2.^f.3 Summary of Results 

The weights for the various heat transport systems, applied to the baseline space station, 
are summarized in table 2.'^!. The pumped two-phase ammonia system used in con- 
junction with two-phase water heat transport Inside the pressurized modules is the light- 
est system. The corresponding capillary two-phase system is 359 lb heavier. The 
pumped two-phase system with pumped water loops inside the modules is 907 lb heavier. 
The pumped liquid ammonia system is heavier by 2126 lb and the pumped freon system is 
heavier by 3699 ib. The total radiator area required iss 6186 ft^ for two-phase ammonia 
systems in conjunction with two-phase water loops; 6690 ft2 for two-phase ammonia 
systems with pumped water loops; 7900 ft^ for pumped liquid ammonia system; and, 8035 
ft2 for pumped freon system. 

2.^4 Cost and Benefits Analysis 

In the final report of the study completed in April of 1983 a cost and benefits assessment 
was given for developing thermal storage systems for both pumped liquid and two-phase 
heat transport concepts. The result indicated that those technology advancements were 
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Figure 2.4-2 High Temperature Two-Phase Ammonia Bus vsath Two-Phase Water Loops 
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Figure 2,4-4 Low Temperature Two-Phase Ammonia Bus with Two-Phase Water Loops 
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Table 2.4-1 System Weight Comparison 
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among the most desirable of the ones identified in that study. It was indicated in that 
study that development costs for the two-phase system would be 5096 higher due to the 
complexity of: 

a. Phase change material packaging. 

b. Thermal interface with the heat transport system. 

In the current study, a further assessment of the pumped liquid versus two-phased heat 
transport system was conducted. Two technologies were identified for advancement 
specifically to support the development of a two-phase system. Tnese are: 

a. Two-phase water thermal transport loops for inhabited environment. 

b. Heat exchanger for liquids in nearly saturated state in zero gravity. 

The quantifiable benefits of these advancements are (i) that the two-phased system is 
less complex than the pumped liquid system, (2) that the two-phased system weighs less 
than the pumped liquid system, which means lower cost to transport the system to orbit, 
and (3) that the radiator area is less for the two-phased system, which means the assem- 
bly labor costs will be lower. 

The two systems compared are given by the pumped Freon-11 system of figure 2.^-6 and 
the pumped two-phased water heat transport system of figures 2.^-3 and 2.^-4. 

The complexity factors were compared using the RCS PRICE modelling technique and 
the result came out $2i.26M for the liquid and $16.08M for the two-phased, which results 
in $5.18M in favor of the two-phased system. 

The transportation costs were calculated using $718 per pound to orbit and the differ- 
ence in system weights. This resulted in $2.66M in favor of the two-phased system. The 
assembly costs were based on $77,000 per 2^-hr day for astronaut time and the assess- 
ment that was used in the last study of 8-labor hours to assemble 100 square feet of 
radiator. This resulted in a $475,000 saving for the two-phased system, 

t 

The cost of advancing these technologies has been estimated at $0,8M for the heat ex- 
changer program and $2.59M for advancing the two-phased water interior loop system 
(assuming use of shuttle test data for heat pipes ratiier than a complete independent 
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flight test). Together these represent an expense for technology advancement for a two- 
phased heat transport system of $3.^M. 

Using the above figures the cost over benefit ratio of advancing technologies to support 
the two-phased heat transport system is O.ftl. This is based on the $3.<>M advancement 
cost divided by $S.32M benefits. 

2.4.5 Conclusions and Recommendations 

The study results show that a pumped two-phase heat transport system provides some 
weight, power, and size reductions compared to a pumped liquid loop system. The two- 
phase system also offers greater flexibility in configuring the space station. 

A capillary two-phase heat transport system offers the advantages of a pumped two- 
phase system with a relatively small weight increase. The capillary system does not 
need the pumps, valves, and controls needed for the pumped two phase system. Conse- 
quently a capillary system is, in principle, a more reliable system. 

A two-phase water heat transport system for pressurized modules provides an additional 
weight savings when used with a two-phase main transport system. A capillary two- 
phase water system would provide increased reliability and reduced vibration and noise. 
Alternative pumping concepts for the pumped two-phase system were considered briefly. 
One concept uses an osmotic pump in place of the baseline mechanical pump. This con- 
cept provides pumping by osmotic pressure that causes solvent to flow through a semi- 
permeable membrane into a solution that flows to the evaporator. This concept requires 
auxiliary mechanical pumps to keep the solution from being diluted next to the mem- 
brane. The weight, reliability, and performance deficiencies of this concept eliminates 
it from serious consideration as an alternate pumping scheme. The other concept con- 
sidered was an ion drag pump that produces fluid flow by creating ions in a corona dis- 
charge. The ions are accelerated in an electric field and impart momentum to the fluid. 
This scheme has tiie advantage of pumping with no moving parts. However, the pumping 
efficiency is only about 10%, high voltages are required, transport fluid must be a dielec- 
tric, and the corona discharge may have degrading effects on the fluid and electrode. 

The results of this study showed that the weight of a two-phase heat transport system is 
approximately 1200/lbm less than that of a comparable single-phase system of identical 
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capacity. This 1296 lower weight alone would probably not be sufficient justification for 
the selection of a two-phase system for the space station. The most compelling reasons 
for the choice of a two-phase transport system are (1) flexibility in locating heat loads 
and reconfiguring experiments, (2) modular growth of the station, and (3) stable tem- 
perature interface with cooling and heating loads over a wide range of operating 
conditions. 

The two-phase system concept, however, has some inherent technical nsks that will 
require expensive space flight testing to resolve. The developmental costs of the two- 
phase system would therefore be expected to be considerably greater than the cost of 
developing a single-phase system. 

Additional information is needed before a sound decision can be made as to which ther- 
mal transport system should be selected for the Initial space station. It is therefore 
recommended that a program be initiated to generate the necessary information to sup- 
port tlie selection of a space station thermal transport system. A three step program is 
envisioned. In the first step, system requirements wouid be established. These require- 
ments would stem from the definition of: (1) system loads such as experiments, equip- 
ment, etc., (2) planned space station evolutionary growth, and (3) space station mission 
planning. 

Candidate single- and two-phase transport systems would be designed and optimized in 
the second program step. These systems would be developed for a baseline station and 
mission drawn from the step one requirements definition study. Dollar cost benefits of 
ea<± transport concept would be quantified for all important system attributes including: 


a. Mass. 

b. Size. 

c. Flexibility/growth. 

d. Reliability. 

e. Maint^nability. 

f. Constructability. 

g. Operation costs. 


In the third step, detailed plans for transport system development wouid be prepared. 

Developmental costs would then be predicted and a cost and benefit analysis performed 
to identify the best thermal transport system concept. 
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Regardless of the final selection of the thermal transport system concept for the space 
station, the potential benefits of the two-phase system warrant immediate technology 
development. Sudi developments are necessary to bring the level of technical maturity 
up to the point required for space station preliminary design. Because a pumped two- 
phase thermal bus system development program is currently in progress under NASA 3SC 
contracts NAS9-16781 and NAS9- 16782, it is recommended that emphasis should be 
placed on development of a two-phase transport loop suitable for thermal management 
within pressurized inhabited environments of the space station. The high performance 
fluids (ammonia or freon) envisioned for use in the main thermal transport bus cannot be 
used in inhabited areas due to their toxicity. Water would be the first choice for the 
v/orking fluid in the internal transport loop. A two-phase design would provide the flexi- 
bility, modular growth capability, and isothermal interface characteristics desired for 
the overall thermal management system. Both mechanically pumped and capillary 
pumped loops should be Investigated. Special emphasis should be placed on developing 
pump and heat exchanger technology that would benefit both the main thermal bus and 
internal transport loop concepts. In addition, capillary pumping for the msiin thermal 
transport system should be investigated because of the potenlial for increased reliability 
and reduced power, noise, and vibration by eliminating mechanical pumps. 

2.4.6 Technology Advancement Plans 

Recent developmental studies for long-life thermal conlrol systems have identified some 
problem areas in the use of pumps on two-phase systems. This technology development 
plan has been derived to study and resolve those problems to bring pump technology to a 
state of readiness for a new start on the Space Station program. Figure 2.4-7 and table 
2.4-2 provide schedule and resource planning information for the pump technology 
advancement. 

Most two-phase thermal control concepts derived for application to the current modular 
manned space station have characterized two kinds of fluid loops. The bus loop most 
often uses a toxic v/orking fluid like freon and ammonia because they have good thermal 
properties. However, for safety reasons, this loop is constrained to avoid exposure to the 
pressurized living spaces. For "d^ose areas, a water loop is suggested for heat transport. 
The device, which will exchange heat between the two systems, is the subject of the 
second thermal management technology plan and the schedule and resource plans are 
given by figure 2,4-8 and table 2.4-3 respectively. 
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The application of two-phase thermal management subsystem in pressurized modules of 
the space station configuration is the third technology for advancement in the thermal 
management area. Reliability and performance are key objectives for the development 
Figures 2.<h9 and table give the schedule and resource information respectively. 
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Figure 2.4-9 Schedule for Two-Phase Water Interior Loop Technology Advancement Program 
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2.5 INTEGRATION OF AUTOMATED HOUSEKEEPING 

This study was conducted to characterize a system for integrating tiie automation of 
several housekeeping subsystems on an irJiabited space station. This integration system 
will be a step toward meeting the autonomy/automation philosophy for the space station 
that was defined by the Concept Development Group (see table 2.5-1). 

In a study completed in early 1983, the cost versus benefits of integrating the automa- 
tion of several utilities producing subsystems on a space station was assessed. The 
results of this assessment indicate that the function of providing this integration could 
produce savings to the space station over a 10-year life of $18^M. The same study indi- 
cated that a large part of the cost of such a system would be the software development 
and the probable use of expert systems technology. These cost figures were assessed as 
being about $9M. Because the system had not been described at a detailed level and 
because the cost and benefits were impressive, it was decided to conduct the current 
study to take a more detailed look at the functions of such a controller. The current 
study also produced a reassessment of the cost and benefits of the system and generated 
a more definitive identification of the applicability of expert systems to the process. 

2.5.1 Approach 

The objective of this study was to obtain a characterization of the integratbig manage- 
ment controller to allow a better understanding of the benefits possible and the tech- 
nology needed for implementing such a controller so that it will provide reliable, real- 
time management of the separate housekeeping cwtroUers on a space station. To 
accomplish this objective, the results of the initial study were extended by a more 
detailed modeling of how a management type controller might be employed. The model 
was then examined to identify options in the implementation that better defined the 
benefits to be obtained from the integration process. 

In performance of this task a system analysis was conducted to update the following list 
of functions to be performed by each of the three automatic housekeeping subsystem 
controllers: 
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Table 2.3-1. Space Statim Autonomy/ Automation Philosoi^y 

^ 

Subsystem/system monitoring and control will be performed onboard. S 

Systems monitoring and control will be automated. 

Fault detection and isolation wili be an automated function for ail subsystems. 

■ 

Redundancy management including reconfiguration will be performed automatically 
onboard. 

Reverification of systems/subsystems elements will be performed automatically on 
board. 

Operations planning and scheduling will be performed onboard. 

The degree of automation will increase as the space station grows and tedinology 
becomes available. 

Collection and analysis of trend data will be automated. 

The space station platform shall have the same degree of automation onboard as the 
manned base. 
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Table 2.5-2: Functions For Housekeeping Controllers 


Electrical Power 

Thermal 

Life Support 

Control voltage at power 
user outlets. 

Control temperature to 
set points within cabins. 

Control oxygen and 
nitrogen supplied to 
cabin. 

Control power levels at 
power user outlets. 

Control temperature at 
heat exchangers for 
specific equipment items. 

Control contamination 
leve l in cabin air. 

Switch sources based on 
sensed status of sources 

Control humidity of cabin 
atmosphere. 

Control quality of potable 
and wash water. 

Removal of CO 2 irom 
cabin air. 


The above table indicates the starting point on independent control functions within each 
of the three housekeeping subsystems on the space station considered in this study. 

These functions are those that relate to maintaining the environment on the space sta- 
tion for the Q-ew and for the mission-peculiar equipment. The list was expanded for 
models of the three subsystems to the level of detail where the control parameters would 
be sensed. 

A systems analysis was performed to develop a concept for integrating the control of the 
three housekeeping functions and to identify the control parameters. 

Based on the interactions identified, functions were defined for the integrating control- 
ler. Functional block diagrams were then developed along with functional descriptions of 
each of those defined. 

Because various mode shifts would be selected and implemented by an integrating con- 
troller, it was necessary to identify the mode shifts and to assess the sequencing of the 
action. The scenarios for operation of an integrating controller were conceptualized in 
this subtask by a systems analysis approach. 

A systems analysis was then conducted for an integrating controller for automated 
housekeeping functions in cooperation with data management specialists to identify 
hardware and software elements of a concept and to isolate technologies to be con- 
sidered for advancement in order to implement the concepts. The use of artificial intel- 
ligence in the form of expert systems was explored to implement the flexibility and 
tolerance for change needed in this integrating controller. 
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2^*2 Technical Discussion 

The automation of three subsystems on an inhabited space station was investigated to 
identify the functions to be performed and the sensing that would be needed. The three 
subsystems were electrical power, life support, and thermal management. The auto- 
mation being considered is that which would be used internal to each of these subsystems 
to enable them to perform their functions automatically. The integration of these auto- 
mated systems deals with interactions between them, with outside factors which affect 
them all, or with trends that involve more than one subsystem. 

Tables 2.5-3 through 2.5-5 show the results of analysis conducted of these subsystem 
concepts and lists the functions and sensed quantities for the automations identified. 

The functions and sensed quantities in these tables were then used to construct an inter- 
face tabulation (see figure 2.5-1) to identify when interactions between the automated 
subsystems could exist and where outside events could influence the overall operation. 
These identifications lead to the definition of functions for the integrating controller. 

The integrating controller is a concept that is intended to provide management level 
control of automated utilities subsystems on a manned space station. Initially this con- 
troller would be largely an advisory service for the astronauts. As such, it would tend to 
replace the advisory service that has been provided by mission control with a more auto- 
nomous interactive system that the astronauts can use on board. Because there will be 
actions that will be repetitive and bothersome to the astronauts, it is a worthy goal to 
seek a fully automatic integrating controller for some functions. 

Based on the interactions shown by figure 2.5-1, it is clear that the three subsystems 
affect each other significantly and that there are outside factors that affect them all. 
The functions performed by an integrating controller would then deal with those inter- 
actions, as shown by figure 2.5-2. Inspection of these indicate the following; 

1. Electrical power load management is needed because both diermal and life support 
are heavy power users and reduction of their usage to balance loads needs to con- 
sider their interacting functions. 
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TABLE 2.5-3 

ELECTRICAL POWER SUBSYSTEM AUTOMATION 

Functions 

o Control solar array orientation 

o Control of solar array selection - segment selections 
0 Regulation of solar array output voltage - shunt regulation 
0 Control o£ battery charge-discharge processes 
0 Battery selections - cell selections 

o Load sharing control of regulators 

0 Shunting for under use control 

o Redundancy Management within the electrical power system 

Sensed Quantities 

o Solar array temperatures 

0 Solar array positions 

o Solar array voltages by sections of the array 
o Battery cell voltages 

0 Battery cell temperatures 

0 Battery cell pressures 

o Battery charge voltage 

o dc/dc converter line voltage 

o Transformer coupled converter output voltage 

o Series resonant inverter (dc/ac) output voltage 

0 Series resonant inverter fuse status 

o Magnetic latching relay position 

o Cable temperature 
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TABLE 2.5-4 


LIFE SUPPORT SUBSYSTEM AUTOMATION 


O2 Generation 


o Control of the flow of water to the electrolysis units 
0 Valve operation 
o Pump operation 

o Control of electrolysis current 

o Control of the flow of H2 away from the unit 
o Valve operation 

o ConiTol of the flow of water away from the unit 
o Valve operation 
o Pump operation 

0 Control of the flow of oxygen away from the unit 
o Valve operation 

o Redundancy management within the O2 generator 
o Detection of failure 

o Abnormal values of several quantities 
o Selection of redundant elements; generate rs/pumps/valves 

Sensed Quantities 

o Partial pressure of cabin O2 
0 Flow rate of input water 
o Pressure of H2 at output 
o Flow rate of water at output 
o Pressure of O2 in storage at output 
o Selected set point condition 

o Status of valves, pumps, generators and storage units 
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TABLE (Continued) 

LIFE SUPPORT SUBSYSTEM AUTOMATION 

N 2 Supply 
Functions 

o Control of the flow of N2 from storage 
o Valve operation 

o Redundancy management functions within the N2 supply 
0 Detection of failures 

o Abnormal values of several quantities 
o Selection of redundant valves 

Sensed Quantities 

0 Cabin pressure 

o Pressure of N2 storage tanks 

o Selected set point 

o Status of valves and storage tanks 

CO2 Removal 

Functions 

o Position of by-pass valves to control air flow to beds 

o Position of by-pass valves to isolate beds for desorption from the cabin 

o Control of electric heaters to create steam to flow through beds being desorbed 

o Control of valves to direct CO2 to the reduction system from the beds being 
desorbed 

o Control of valves to provide I^genic water for steam into desorbed beds 

o Redundancy management 

o Detection of abnormal sensed values 

o Selection of redundant elemenis: fans, by-pass valves, beds, and steam 
generators 
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TABLE 2.5-^f (Coatinued) 

LIFE SUPPORT SUBSYSTEM AUTOMATION 

Sensed Quantities 

o Partial pressure of cabin CO2 
o Flow rate of water at input to steam generator 
0 Pressure of CO2 in accumulator at output 
0 Temperature of steam in steam generator 
o Flow rates at desorbed bed 

o Status of beds being used for absorption and being desorbed 
0 Status of valves and fans 
0 Selected set point 

CO2 Reduction 

■ 

Functions 

o Mixing of H2 and CO2 

o Flow of mixed CO2 and H2 through filter to the reduction unit | 

0 Pump and valve control for water accumulator at reduction unit output 

o Redundance management within the CO2 reduction unit 

o Selection of redundant eiementss reduction unit, valves, and accumulator 
o Failure detection based on abnormal sensed values 

o Cooling for .unit 

Sensed Quantities 

o Flow and pressure of gases at input 
o Temperature of unit 

o . Flow and pressure of gases at output of unit 
o Flow of water to accumulator 
0 Capacity filled with water in accumulator 
o Flow of water out of accumulators 
o Status of valves and accumulators 
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TABLE (Continued) 

LIFE SUPPORT SUBSYSTEM AUTOMATION 


Trace Contamination Control (TCC) 


Functions 

o By-pass valves to control air flow through beds 
o Annunciation of below normal bed status 
o Control of power to electric heaters 

o Redundancy management within the trace contamination control system 
o Failure detection based on abnormal sensed values 
o Selection of redundant elements: alternate fans; paths through beds, and 
o^ddizer 

Sensed Quantities 

o Level of contamination 

o Temperature of oxidizer 

o Flow through i inits 

o Status of fans, valves, oxidizer heater and beds 
o Selected set point 
Potable Water Process 


Functions 

o Control of water flow to post-treat 
o valves 
o pump 

o Control of cycling in post-treat and Water Quality Monitor (WQM) 
o valves 
o pumps 
o WQM processes 

o Control of flow to selected storage tank 
o Control of iodine adtStion in storage tank testing process 
o Confrol of overflow to hygienic water 
o Control of water heater 
o Control of use flow out of storage tanks 
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TABLE 2.5-4 (Continued) 

LIFE SUPPORT SUBSYSTEM AUTOMATION 

Functions (Cont) 

o Redundancy management with the potable water processor system 
0 Failure detect 

o Seclection of redundant elements: accumulators, water quality monitors, 
(WQM), tanks, valves, and beds 

Sensed Quantities 

o Capacity filled in accumulators 

o Measured contaminants in WQM 

o Capacity filled in storage, test, use tanks 

o Iodine level in storage tank test processing 

o Post treat valve and bed status 

o Water temperatures in system 

o Storage tank valve status 

o Water flow rates in system 

Hygenic Water Process 

Functions 

o Control of pre-treat pumping 
I o Control of pre- treat biopal VRG 20 addition 

o Control of p’Ti'ping and valving into the vapor-compression distillation (VCD) unit 
o Control of compression in VCD 
o Control of heating in VCD 

o Control of conductivity testing of VCD condensate and valving for output 
o Control of post-treat valving and pumping 
o Control of WQM processes 
o Control of flow to fill-use tanks 
o Control of flow out of fill-use tank 
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TABLE 2^5-it (Cootinusd) 

LIFE SUPPORT SUBSYSIEM AUTOMATION 


Functions (Cent) 


o Redundancy management within the hygenic water processor system 
o Failure detect 

o Select redundant elements: VCD, valves, fill tanks, pumps and heaters 

Sensed Quantities 

o PH level in pre-treat 
o Flows in pre- treat 
o Waste holding tank capacity filled 
o Valve status indicators 
o Waste tank capacity filled 
o Sludge tank capacity filled 
o Flows into VCD 
o Pressure in VCD 
o Temperature in VCD 
0 Conductivity of VCD condensate 
o Flow of condensate from VCD 
o Measured contaminants in WQM 
o Post treat valve and bed status 
o Flow rates in post treat and storage 
o Storage tank valve status 
o Capacity filled in storage tanks 
o Capacity filled in accumulators in system 
Wash Water Process 


Functions 

o Control of pumping to work holding tank 
0 Control of pumping and valving to hyper-filtration process 
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TABLE 2.5-if (Continued) 

LIFE SUPPORT SUBSYSTEM AUTOMATION 


Functions (Cont) ' 

o Control of heating in hyper-filtration process ii 

o Control of valving and pumping from the hyper-filtration process i, 

o Control of the addition of sodium hypochlorite in post-treat ‘ 

o Control of the addition of iodine in post-treat 

o Control of pumping and valving for post-treat * 

o Control of pumping and valving for storage of wash water 

o Redundancy management within the wash water processor system t! 

o Failure detection 

o Selection of redundant elements: pumps, valves, hyper-filtration units, and 
tanks 

Sensed Quantities 

o Flows to and from holding tank 
o Flows to and from the hyper-filtration processor 
o Temperature of hyper-filtration processor 
o Capacity filled in holding tank 
o Capacity filled in hyper-filtration process 
o Measured contaminants in WQM 
o Post-treat valve and bed status 
o Flows for post-treat and to storage 
o Storage tani- valve status 
o Capacity filled in storage tanks 

o Quantity of iodine and sodium hypochlorite available for use 
o Capacity filled in sludge tank 
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TABLE 2.5-5 


THERMAL CONTROL AUTOMATION 


o Control of cabin air flow through heaters 
o Control of heaters 

o Control of heat exchanger condensate flow to separators 
o Control of water flow out of separators 

o Control of positions of steerable radiators or selections of selectable radiators 

o Control of coolant flow - valve positions or pump speeds 

o Redundancy management within the thermal control system 
o Sensed failures from abnormal sensor values 

o Selection of redundant elements: fans> heaters^ heat exchanges, separators, 
pumps, and valves 

Sensed Quantities n 

o Temperature of cabin air 

o Humidity of cabin air 

o Input air flow to heater 

o Condensate flow at heat exchanger 

o Water flow out of separators 

o Air flow out of separators 

o Heater temperature 

o Set point status 

o Equipment status 

o Position and rate mformation for steerable radiator servos 


o Valve positions 
o , Pump speeds 
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VEEN HOUSEKEEPING FUNCTIONS 


INTERFACE BETWEEN THERMAL AND LIFE SUPPORT 


o Temperature of cabin air 
o Hunicity of cabin air 

o ‘Jt’arer flow out of separators {water to life support) 


o Air flow out of separators (air to life support) 


OUTSIDE FACTORS WHICH EFFECT HOUSEKEEPING 

o Li^^tside/Darkslde 
o Electrical power solar arrays 
o Thermal radiators 
o Outside lighting 
o EVA constraint 


o Crew size and level of activity 
o Life support load 
0 load on electrical power 
o Energy input to thermal 
o Moisture input to thermal 

o Distribution of life support materials, power loads, and 
thermal loads 

o Compliment of Experiments 
o load on electrical power 
o Load on life support materials 
o Constraint on dumping of waste 
o Thermal/humidity input 

o Distribution of life support materials, power loads, and 
thermal loads 

o Shuttle Docked or Away 
o *Air mixing between shuttle and station 
o Possible extra crew 
o Possible power sharing considerations 
o Passible thermal sharing considerations 

o EVA or not 

o Extra toad on life support before and after 
o Less load during 

o Maintenance 

o System shutdowns while need for functions continues 
o Effect of maintenance on variations in performance of 
systems 

o Effect of maintenance on crew activity - EVA 




oo 


ANNUNCIATION 
AND DATA 
DISPLAYS 


COMMAND INPUTS 
(ASTRONAUTS 
OR GROUND! 



PARAMETERS 


D 

OO 

0 

1 

K) 

vj 

VO 

W 

Kn 


Figure 2.5-2 Uterfaces Between an Integrating Controller and Automated Housekeeping Subsystems 
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2. Materials transfer management is needed because outside factors affect the loca- 
tion of needs as weil as the location of the availability of life support materials 
around the space station. In many cases transfers need to be considered against 
scheduled events and against dumping constraints as well as impacts on power and 
thermal loading. 

3. Intersubsystem failure isolation is needed because failure diagnosis outside of sub- 
system boundaries will have to be conducted in order to trace the cause through 
the interacting functions. For example, an apparent failure of the separator in the 
thermal or humidity control system could be caused by an actual failure in the 
Water Quality Monitor (WQM) in the life support which is producing a backup into 
the accumulator receiving the condensate from the separators. In this case failure 
isolation within a subsystem would not be sufficient to find Ihe problem. 

4. Intersubsystem redundant path selection is needed because selection of redundant 
paths in response to failures or maintenance shutdown will have to consider the 
impact on interacting subsystems. 

5. Maintenance schedule management is an integrated function since changes to the 
timing of maintenance actions for one subsystem can have affects on tiie operation 
and maintenance of other subsystems. This is because mainten^ce may cause 
temporary shutdowns and may result in changes in performance of the maintained 
subsystem which affect others. 

6. Start-up integration is needed to control the interdependent sequencing of bringing 
subsystems on line so that outputs are available before the need is created. 

Figures 2.5-3 thru 2.5-8 give functional diagrams for these six functions. 

Scenarios, for initialization of a space station system and for a shift in life support 
modes on a space station, were developed to describe the opeiating environment for the 
integrating controller. 

An initialization scenario is to describe events that might occur as a space station 
module is initialized for habitation by the crew. It is assumed that ihe shuttle is 
attached and that the crew relies on die shuttle systems to support the initial EVA. As 
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Figure 2.5-3, Functional Block Diagram for Electrical Power Load Management 
by an integrating Controller 
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Figure 2,5-6. Functional Block Diagram for inter-subsystem Redundant Path Selection 
by an intagtating Controller 
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Figure 2,5-7 Functional Block Diasram for Maintenance Schedule Management by an integrating Controller 
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can be seen, no attempt is made to work out the specific number of orbits for this pro- 
cess. The initialization crew will start out using EVA and then will go to shirt sieeves 
after orbit L* The initialization crew wouid be two or possibly three astronauts and 
would be joined by the remainder of the crew after orbit W. 




Orbit 

(1) 

Close c^ins and establish initial atmosphere 

N 

(2) 

Cabin power available 

N + M 

(3) 

Cabin heat exchangers 

N+M+1 = 

W 

Cabin Trace Contamination Control (TCC) on 

N+M-fl = 

(5) 

Cabin dehumidihers on 

N+M+1 = 

(6) 

02 generators on 

L+R = Z 

(7) 

N2 supply opened 

L+R = Z 

(8) 

Cabin air heaters on 

L+R = 2 

(9) 

CO 2 removal on 

Z+1 

(10) 

CO 2 reduction on 

Z+2 

(11) 

Crew begins cabin occupancy 

2+S = W 

(12) 

Potable water loop on 

Z+S = W 

(13) 

Hygienic water loop on 

Z+S = W 

(1(f) 

Wash water loop on 

Z+S = W 


The mode shift sequence is the resuit of a change in the life support subsystem operating 
mode between the nominai, degraded, or emergency set points. Again this is a concep- 
tuai sequence of events to be described more specificaily after the space station design 
becomes more defined. 

1. Mode change selected either by crew or the integrating controller. 

2. The integrating controlier then adjusts control limits for each automatic 
system reference to correspond with selected mode. 

3. System configured for mode diift as necessary by commands from the inte- 
grating controller. 

a. Materials transfer 

b. Power Adjustments 

c. Path Selection 

4. Maintenance schedule adjt^ted as needed. 

5. Annunciation to crew. 
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6. Implement mode shift. 

An integrating controller will consist of onboard central and distributed processors that 
will initially be supported by an earth-based central data processing facility, which can 
be used by employing the telemetry link. The processing functions will be largely in the 
onboard central processor for all decision making and command generating. The dis- 
tributed processors will be used for data collection and command execution functions. 
The earth bound facility will be used for some off line comparisons and determinations, 
especially for failure diagnostics and logistics control. Figure 2.5-9 shows a typical pro- 
cessor hierardiy and data path connection concept for a integrating controller. The 
diagram indicates where the functions are in the central processor and where they are 
distributed. 

The following functions of the integrating controller are indicated to be definite candi- 
dates for some expert systems processing. 

1. Electrical power load management - the MSFC has a study which is being 
conducted by Martin Marietta and the Indication from that study is that 
expert systems apply to this function. 

2. Redundant path selection - work is being done to apply expert systems to this 
problem for nuclear power plants. 

3. Maintenance schedule management - this general area is considered to be a 
promising application of expert systems. 

All of the other functions were considered fay artificial intelligence specialists to be 
good candidates for at least partial application of expert systems. 

Any estimate of the size of the expert systems parts of an integrating controller is con- 
strained by the following: 

1. TTie preferred current method of developing an expert system is to use an expert 
system language analogous to a programming language for conventional automa- 
tion. The number of statements in a conventional program can vary drastically 
depending on the language. In the case of expert systems, there is probably at 
least a 3:1 variation in number of rules depending upon the language used. 
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Figure 2.5-9 Processing Functional Diagram of Integrating Controller for Automated Housekeeping 
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2. Expert systems do not have to be developed using rules. Rules are a knowledge 
representation technique. There are other ways of representing knowledge 
including! 

Logic 

Networks 

Frames 

Hybrid 

This is one reason why an integrating controller would involve several expert systems for 
its different types of functions. 

Given the above caveats, it was estimated that as an example, the intersubsystem failure 
isolation function expert system would involve from i, 000-3, 000 rules, and in that case 
using rules for estimating is probably a good way to go. 

Factors to consider when describing whether to use space borne or ground based compu- 
ters for the integrating controller include: 

1. Criticality— will the astronauts be threatened if access to the integrating control- 
ler is interrupted? 

2. Resource usage— does the integrating controller use an excessive amount of space 
borne computer resources? 

3. Data bandwidth— does the integrating controller process so much data that trans- 
mitting it to earth would jug up the communications channels? 

Because of the criticality of the failure isolation function and redundant path selection 
function, they would be high priorities for space borne implementation. Maintenance 
scheduling could probably be ground based at least in the early stages of the space 
station. 

In order to estimate the space borne computational capability required, several assump- 
tions will be made: 

1. The expert systems used will be programmed for the onboard system using the LISP 
programming language. (LISP is a heavy user of resources). 
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2 * The space station has a distributed processing system consisting of generai purpose 
as well as special purpose processors. 

3. General purpose processors are machines with 32-bit CPUs, 2 MIPS throughput and 
1 MB of memory. 

Mass storage will be available to store expert systems rules when not actively 
being processed. 

Based on these assumptions, it is estimated that an expert system implementation would 
require a general purpose processor for active procesang of each expert system function 
of the type exemplified by intersubsystem failure isolation syswm. 

Any large expert system might require a special purpose processor, and unless the func- 
tion was extremely critical for crew safety, it would not be space borne. 

To estimate the effort needed to develop an expert system a single function such as the 
failure isolation is estimated to require at least 5-10 man-years of effort. Assuming one 
expert system per function, 30-60 man-years of effort would be required. (Currently, 

5 man-years seems to be the quickest any expert system can be developed). 

All of this indicates that expert systems have a role to play in the integrating controller 
concept, but that they are, when based on current technology, heavy users of computa- 
tional resources and development effort. 

2.5.3 Concept Trades 

The results of the concept characterization studies for an integrating controller are 
basically the definitions of functions to be performed by such a controller, and concepts 
for processing of those functions onboard the space station or on the ground using dis- 
tributed as well as centralized architecture. This section discusses the comparisons 
conducted with respect to these characterizations and the identification of technology 
advancements needed. 

Figure 2.5-10 gives a trade of the functions of the integrating controller against five 
fairly nonquantifiable criteria. 
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Figure 2.S-10 Trade of integrating Controller Functions 
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These comparisons indicate that the start-up integration and maintenance schedule man- 
agement are of lower priority than the other four functions. This seems somewhat rea- 
sonabie because the space station wouid need the first four for smooth and safe oper- 
ation, while the last two would be more like convenience functions. 

In general, trade on architecture favor a dirtributed system vAiere the requirements for 
computing capacity indicated by the function do not dictate extremely large units, which 
would be practical to duplicate on board the space station. 

The comparison of a fully automatic system versus one where the astronauts interact 
thru a computer terminal involves human preferences. In many cases the astronauts 
would prefer not to be bothered with routine diagnosis and corrective action but in 
others such as scheduling and logistics the astronauts would want to maintain control. In 
a few cases such as attitude control or some power control the diagnosis and corrective 
action could require faster response than that which is consistent with human capability 
and that would favor the fully automatic approach. Finally, the acquisition of a know- 
ledge base to develop the integrating controller system will benefit by the interactive 
experience of astronauts during the early missions. All of this indicates that the early 
space station will be characterized by a great emphasis on interactive controllers but as 
the station matures many functions will become fully automatic. 

2.5.4 Cost and Benefits Analysis 

Based on the integrating controller characterization developed in this study and the 
trade study considerations identified above, an update of the cost and benefits for advan- 
cing the expert systems technology can be established. In section 4.1.8 of volume n of 
the Advanced Platform Systems Technology Study Final Report, a cost and benefits 
estimate was made for the expert systems technology for an integrating controller. In 
the current study, we have developed a more detailed description of the functions of the 
controller and have focused on the programmatic trades with respect to those functions 
and that allows a more realistic estimate of costs and benefits. 

The following assumptions are established for the cost update of this current study. 

1. Six expert system functional elements plus one expert system selection element 
will be considered. 
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2. Each element is equivalent to one R1 expert system program (850 rules) except the 
intersubsystem failure isolation element, which is assumed to be 2,000 rules (see 
section 5.3.6). TTiis gives a total of 7,100 rules for the integrating coniroller 
expert systems. 

3. Based on the productivity reported in section 5.3.6, each rule requires 2 days of 
labor to develop. This is better than the productivity rate of 5 labor days per rule 
used in the previous study. We will assume the more conservative 5 days per rule 
rate. 

Assume a labor rate of $400.00 per-man day for expert systems software develop- 
ment (this is nearly double the rate assumed for the last study). 

5, Assume $1M for verification of each element for a total of $7M. 

6. Based on the estimate of one general processor for each online function plus one 
for the expert system selector, we can estimate that at least three onboard general 
processors would be needed to implement the system. Assuming $1M for each we 
have $3M for additional hardware. 

Based on the above assumptions a cost figure for the expert systems development and 
implementation is $24.2M. This includes approximately $12M for establishing flight 
resident software and for a set of flight computers. 

For the benefits estimate we will consider a phased introduction of the integrating con- 
troller expert systems. This means that the yearly savings assumed in the previous study 
would be reduced. 

The following assumptions apply to the benefits estimates for this study. 

1. The labor to monitor the space station systems would be phased out as the inte- 
grating controller is phased in as follows: 

a. For year 1: six ground-based mission controllers plus fi time astronaut 
(full coverage) 

b. For year 2 thru 5: one ground-based mission controller plus 55 time 
astronaut. (Reduction of five ground-base mission controllers for 4 
years.) 

c. For yea* 6 thru 10: 1/10 time ground-based mission controller plus 1/10 
time astronaut. (Reduction of 5.9 mission controllers and 0.4 astronaut 
for 5 years). 


96 


D180-27935-1 


2. Mission controiler iabor rate is $1500 per 24-hour day or $550,000 per year for each 
controlier 

3. Astronaut iabor rate is $77,000 per 24-hour day or $28,200,000 per year. 

4. Resuppiy and maintenance cost savings due to the integrating controiler are esti- 
mated as $25M over a 10-year mission due to more efficient use of resources 
onboard and more managed maintenance operations. 

5. Half of the above benefits of an integrating controlier can be attributed to use of 
expert systems. 

Based on the above assumption the benefits of the expert systems part of an integrating 
controller are estimated at $54.0M. 

* 

The resulting cost to benefits ratio then is 0.44. This is a significant movement from the 

0. 098. ratio estimate of the previous report but still leaves the expert system develop- 
ment with ail the associated unquantified benefits as an attractive technology for 
advancement. 

2.5.5 Conclusions 

The conclusion from this study are: 

1. The integrating controller has real and useful functions on a space station. 

2. The implementation of the controller would profit from expert systems 
programming. 

3. The implementation will be phased and updated during the early years of the space 
station operations. 

4. The Costs are high but so are the benefits. 

5. This technology advancement is essential if the space station autonomy/automation 
philosophy is to be implemented. 

2 * 5,6 Technology Advancement Plans 

The integration of automated control systems for space station housekeeping subsystems, 
such as the electrical power subsystem, life support, and thermal control, would provide 
cost savings as well as safety, efficiency, and maintainability benefits to space station 
design and operation. 
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Table 2 , 5 - 6 . FY24, RTOP Submissions Related to Technology Applicable to 
The Space Station Integration of Automated Housdceeping 
System Advancement 


Center 

Title 

ObiecUves 

Benefits 

Ames 

Research Center 

Advanced Concepts for 
Knowledge-Based Expert 
Systems 

0 Development of basic computer 
science tools required for know- 
ledge-based expert systems. Will 
provide the impetus for automated 
spacecrafti space platforms, 
scientific instruments, and ground 
based stations. 

o Use of these tools in auto- 
mated expert systems will 
resuit in more scientific 
return per unit dollar and 
minimum labor-intensive tasks. 

Langley 

Research Center 

Automation Systems 
Research 

0 Develop and support the 
technology base required to design, 
develop, and automate teleoperator 
and robotic systems. 

0 Enhance man's capabilities 
for future space activities 
including servicing, main- 
tenance and repmring, struc- ' 

tural assembly, and space 
manufacturing. 

Lyndon B. 
Johnson Space 
Center 

Automations Technology 
for Manned Space Systems . 

o Develop automation technology as 
applied to manned space transporta- 
tion and space station systems. 

0 Certain systems, when the 
present level of technology and 
existing manned transportation 
complexity as extrapolated from 
systems to those of the future 
and that required by the space 
station, will be entirely 
impractical unless it is 
automated. 

Jet Propulsion 
Laboratory 

Autonomous Spacecraft 
Systems Technology Program 

0 To develop expert systems 
for a manned space station 

o Autonomous operations will 
have several benefits including 
reducing the on-orbit work load 
of the space station crew. i 

and reducing the number of ground 
support personnel and resources re- 
quired to support SS dedication; 
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A survey of related RTOP's for FY 8^^ (table 2.5-6) indicates that the technology base is 
being developed in this area but that base should be expanded to meet the needs identi- 
fied by this study. While the specific goals of this plan are unique, the integratio:) of 
automated housekeeping functions impacts not only the subsystems mentioned but the 
data management area as well. The architecture of space station data management 
must support the design requirements imposed by these developments. The plan for the 
technology advancement associated with integration of automated housekeeping is pre- 
sented by the schedule and resource information of figure 2.5-U and table 2.5-7, 
respectively. 
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